Subject: Proposal for Capabilities Exchange pkt

From: [email-masked] (Scott Adams)
Date: Wed, 11 Aug 1993 14:12:36 -0400 (EDT)

Since no one else has offered a specific proposal for a packet format
for Capabilities exchange, I thought I'd just go ahead and do it.
Consider it a place to begin formulating a proposal to go before the
SIG (hopefully for the September meeting).

Scott

-------------------------------------------------------------------

           SSP Capabilities Exchange Packet Format

The new SSP CapabExch packet is of message type 0x20.  It has an SSP
Control type header (since all other initial messages will contain
this type), with Data Link fields set to zero.  CapabExch packets are
exchanged between two DLSw partners only once after the DLS Transport
"Tunnel" has been established (see my proposal for managing TP
connections).  The exchange is of the type "here's what I can do, now
tell me what we will do together," where one DLSw sends a CapabExch
packet and waits for an acknowledging packet.  The initiating
CapabExch packet is coded to present all capabilities supported by the
initiating DLSw, including mutually exclusive options.  The
acknowledging DLSw does an "AND" of these capabilities with its own to
obtain the intersection of the two switche's capabilities.  It then
selects among mutually-exclusive options from within that intersection
set of capabilities and fills out the acknowledging CapabExch packet
with only those capabilities.  It is the capabilities in the
acknowledging CapabExch packet that are used by both DLSw.

The DLSw partners choose which initiates capabilities exchange based
on an unsigned 32-bit comparison of the two DLSw's IP addresses.  The
DLSw with the "lower" IP addr initiates the exchange.  It sends a
CapabExch packet and sets a Capability Exchange Timer, then awaits the
returning CapabExch packet from its partner.  The Capability Exchange
Timer duration must be greater than the TCP connection time-out period
(for example, three minutes).  This is necessary in order to
distinguish between a true TP connection error and a DLSw partner that
doesn't support capabilities exchange.  If the timer expires, and
there hasn't been a connection error, then it is assumed that the
partner DLSw doesn't support capabilities exchange, and thus defaults
to DLSw ala RFC 1434 (might refer once again to my earlier proposal on
Transport Connection Management, which includes this default
behavior).

The data portion is Tag-Length-Value encoded with the capability
information.  Tags are 16 bits, lengths are 16 bits and give only the
length in octets of the following value, and values are from 0 to 64K
octets in length.  Values may be anything.  Bit ordering is highest
order bit first, lowest order bit last.  General octet ordering is
most significant byte first, least significant byte last (where most
significant byte means the highest order bits of for example a 32-bit
word).  I've thought of the following capabilities and TLV encodings.
Consider these just examples, and not an exhaustive list.

Note that all numeric and bit field values are shown in hexidecimal.

     Name/Description        type   Tag    Len    values
     ----------------        ----   ---    ---    ------
Transport Cnxn Mgt           bitf  0x0001 000x04  
  Standard (RFC 1434)                             0x00000001
  Full Duplex Static                              0x00000002
  Full Duplex Dynamic                             0x00000004
  Multiple Full Duplex Dynamic                    0x00000008

Loop Prevention              bitf  0x0002 0x0004  
  Spanning Tree                                   0x00000001

Initial Pacing Window        int   0x0003 0x0004  0x00000007

No NETBIOS support           null  0x0004 0x0000  

No APPN/SNA support          bitf  0x0005 0x0004  
 for PU 2.0                                       0x00000001
 for PU 2.1                                       0x00000002
 for PU 4                                         0x00000004
 etc.

X.25 PLP over LLC 2          null  0x0008 0x0000  

Vendor Name                  strn  0x0010 0x0020  "Cayman Systems, Inc."

Vendor Name                  strn  0x0011 0x0020  "GetorBox DLS"

Vendor Release               int   0x0012 0x0004  0x00010000